home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000581_connolly@pixel.convex.com _Tue Jan 19 07:22:45 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  5KB
  1. Return-Path: <connolly@pixel.convex.com>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA17473; Tue, 19 Jan 93 07:22:45 MET
  4. Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA18250; Tue, 19 Jan 1993 07:38:01 +0100
  6. Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
  7.     id AA05016; Tue, 19 Jan 93 00:37:05 -0600
  8. Received: from localhost by pixel.convex.com (5.64/1.28)
  9.     id AA19993; Tue, 19 Jan 93 00:37:02 -0600
  10. Message-Id: <9301190637.AA19993@pixel.convex.com>
  11. To: jim@wilbur.njit.edu (Jim Whitescarver)
  12. Cc: TONYJ@scs.slac.stanford.edu, al@eies2.njit.edu, cis!bieber@dxmint.cern.ch,
  13.         murray@eies2.njit.edu, reddy@wilbur.njit.edu, roxanne@eies2.njit.edu,
  14.         www-talk@nxoc01.cern.ch
  15. Subject: Re: INPUT tag (was: Searching) 
  16. In-Reply-To: Your message of "Sat, 16 Jan 93 13:26:25 EST."
  17.              <9301161828.AA08431@njitgw.njit.edu> 
  18. Date: Tue, 19 Jan 93 00:37:01 CST
  19. From: Dan Connolly <connolly@pixel.convex.com>
  20.  
  21.  
  22. >We may create a default text to be used with the comment feature, which
  23. >will give all input/var field values in rfc822 style for mail based submission
  24. .
  25. >
  26. >At issue are:
  27. >
  28. >- handling typed inputs, including texts.
  29. >- applying inputs to search defaults. positional? named? override mech?
  30. >- applying inputs to go to defaults?
  31. >- getting data from users environment, e.g. users mail address.
  32. >- how the fields will be substituted into hrefs within the sgml context. scope
  33. ?
  34. >- saving updated input values in bookmarks?
  35. >- communicating variables to activity scripts. (our "do" choice)
  36. >
  37. >We need a mechanism to assign arbitrary attributes to anchores and documents.
  38. >These may share name space with input variables and VAR tagged data.
  39. >
  40. >If the INPUT and VAR tags could assign an entity value that we can use as
  41. >&name; within hrefs, that would serve us well enough.  But, is that legal sgml
  42. ?
  43. >It will require a second html parse of hrefs when they are selected.
  44. >
  45. >Our expertise with sgml is limited-- we need a quick and dirty way to pass
  46. >data to activity scripts.  We are far from being able to make a final
  47. >proposal to the web community.  The minimal may be:
  48. >
  49. >Tag    Attributes
  50. >
  51. >INPUT    name, length, default, help
  52. >VAR    name, timeout
  53. >
  54. >The default search would positionally concatonate inputs into keyword position
  55. s.
  56. >Documents containg VAR info would not be cached longer than timeout.
  57. >
  58. >It seems that there is interest in fully interactive hypermedia within the web
  59. >context.  All proposals/feedback is welcomed.  Hopefully we can do it together
  60.  
  61. [I'm going over old mail, replying to stuff I missed. I confess I
  62. can't make much of this sketch. But from what I understand...]
  63.  
  64. I need examples to help me think. Tell me if this example matches
  65. your model:
  66.  
  67. The client C sends GET foo to server S. S returns:
  68.  
  69. <HEAD>
  70. <TITLE>Search Template</TITLE>
  71. <QUERYFORM base="medibase">diagnose condition where age is <recall name="age">
  72. and symptoms includes (<if name="headache">headache</if>
  73. <if name="blackouts">blackouts</if>)
  74. </queryform>
  75. </HEAD>
  76. <BODY>
  77. How old are you? <input name="age" type="number"
  78. width="5" help="http:s/help/inputs#age">
  79. <P>
  80. Do you have any of the following symptoms?
  81. <UL>
  82. <li>headach? <input name="headache" type="boolean" width="3">
  83. <li>blackouts? <input name="blackouts" type="boolean" width="3">
  84. </ul>
  85.  
  86. The client displays the body of the document with a blank
  87. for the age, and check-boxes for the symptoms, and a 
  88. "query" button (similar to a "search" button in response
  89. to <ISINDEX>). The user fills in the blanks and clicks
  90. the query button. Then the client uses the QUERYFORM
  91. to compose its query from the inputs. It sends
  92.  
  93. GET medibase HTRQ/1.0
  94. Accept: text/plain
  95.  
  96. diagnose condition where age is 25
  97.  and symptoms includes (blackouts).
  98.  
  99. to the server. The server performs the query on the medibase
  100. database and returns some document.
  101.  
  102. Where does the volatile data (<VAR> stuff) come in?
  103.  
  104. This would require some additions to the DTD:
  105.  
  106. Inside HEAD, we'd allow QUERYFORM:
  107. <!ELEMENT queryform - - (#PCDATA|recall|if|...)+>
  108. <!ATTLIST queryform
  109.     base CDATA #IMPLIED -- URL to search defaults to current doc --
  110.     >
  111. <!ELEMENT recall - O EMPTY>
  112. <!ATTLIST recall
  113.     name IDREF #required -- points to an input element -->
  114. <!ELEMENT if - O (#PCDATA|if)+>
  115. <!ATTLIST if
  116.     name IDREF #required -- points to input element -->
  117.  
  118. Then inside BODY, we'd add the INPUT element:
  119.  
  120. <!ELEMENT input - O EMPTY>
  121. <!ATTLIST input
  122.     NAME ID #REQUIRED
  123.     WIDTH NUMBER #IMPLIED
  124.     DEFAULT CDATA #IMPLIED
  125.     HELP CDATA #IMPLIED -- url of help info --
  126.     >
  127.  
  128. This would require changes to both the server and the client,
  129. but I don't see any way around that.
  130.  
  131. It's not a major change to HTML -- just a few more elements.
  132. The way I suggest you associate input variables with things
  133. in the query is through the ID/IDREF mechanism as above.
  134.  
  135. Does this jive at all with what you're thinking?
  136.  
  137. Dan
  138.